Exceptions

Overview

Unlike in Java or C++, exceptions are not classes (or interfaces) in IDL. They are second-class objects in IDL. They are more like C structs than anything else.

In IDL, you cannot create hierarchies of exceptions like you can in Java or C++, but we'll see that the IDL-to-Java mapping (just as the IDL-to-C++ mapping), does make them classes in Java, and does arrange them in a shallow hierarchy.

In IDL, the designer of an interface specifies that an operation can raise an exception by using the raises keyword in IDL. This is similar to the throw specification in C++ or the throws specification in Java. When you use the exception keyword in IDL you create a user-defined exception. CORBA already defines a set of standard system exceptions, which are generally raised by the ORB libraries (but anybody is allowed to raise them) to signal systemic error conditions like:

Server-side system exceptions... resource exhaustion, activation failure, etc.
Communication system exceptions... losing contact with the object, host down, cannot talk to ORB daemon (orbd), etc.
Client-side system exceptions... invalid operand type, anything that occurs before request is sent (e.g., marshaling), or after result comes back (e.g., unmarshaling).

An interface designer does not have to say anything explicit in the IDL interface for his operations to become capable of throwing system exceptions -- he has no choice. All IDL operations can throw system exceptions when invoked.

This makes sense, because no matter how trivial an operation's implementation is, the potential of an operation invocation coming from a client that is in another process, and perhaps (likely) on another machine, means that a whole range of errors is possible.

Therefore, a CORBA client should always catch CORBA system exceptions. Moreover, developers cannot rely on the Java compiler to notify them of a system exception they should catch, because CORBA system exceptions are decendents of java.lang.RuntimeException.

All System Exceptions have the same structure, shown below.

exception <SystemExceptionName> {
		unsigned long minor;		// more detail about error
		CompletionStatus completed;	// yes, no, maybe
}

Even though exceptions cannot be related in a hierarchy in IDL, the IDL-Java mapping organizes exceptions into this shallow hierarchy:

java.lang.Exception
   java.lang.RuntimeException
      org.omg.CORBA.SystemException
          BAD_PARAM
          //etc. 
   org.omg.CORBA.UserException
      Stocks.BadSymbol
      //etc.

org.omg.CORBA.SystemException is a subtype of java.lang.RuntimeException, and org.omg.CORBA.UserException is a subtype of java.lang.Exception.

Each of the set of predefined system exceptions is a subtype of org.omg.CORBA.SystemException. Each user-defined exception specified in IDL results in a generated Java exception class which is a subtype of org.omg.CORBA.UserException.